1 Позиционирование и границы протокола
Глава 1: Позиционирование и границы протокола
1.1 Роль CAP в экосистеме iFay
Control Authority Protocol (CAP) выполняет единственную и чётко определённую основную функцию в экосистеме iFay: проверка того, получил ли Fay (iFay или coFay) авторизацию от своего человека-хоста (Natural_Person) или официальной должности (Official_Post) для законного доступа к ресурсам терминала (Terminal_Resource).
В частности, протокол CAP отвечает за следующее:
- Проверка авторизации: Когда Fay запрашивает доступ к программным или аппаратным ресурсам терминала, протокол CAP проверяет, являются ли предъявленные учётные данные авторизации (Authorization_Descriptor или Trusted_Ticket) легитимными, действительными и не отозванными. Например, когда iFay пользователя хочет открыть камеру телефона для фотографирования, терминал должен сначала проверить, что данный iFay действительно авторизован пользователем для использования камеры
- Управление сеансами: Создание сеансов управления (Session) для Fay, прошедших проверку авторизации, и управление полным жизненным циклом этих сеансов. Например, после получения авторизации iFay начинает работать с браузером — весь процесс от открытия до закрытия браузера представляет собой полный сеанс управления
- Координация управления: Координация распределения и передачи управления ресурсами терминала между несколькими Fay или между Fay и пользователями-людьми. Например, дрон, управляемый вручную, необходимо передать Fay для автономного полёта; или два iFay должны последовательно использовать один и тот же принтер
- Многоуровневый доступ к ресурсам: Многоуровневое управление доступом к ресурсам по типу операции (чтение, запись, выполнение, конфигурирование). Например, для чтения данных датчика температуры iFay требуется только разрешение read, тогда как для изменения настройки температуры кондиционера необходимо разрешение write
- Обнаружение активности: Мониторинг состояния активности действующих сеансов и своевременное освобождение ресурсов, занятых недействительными сеансами. Например, после потери связи iFay из-за сетевого сбоя терминал обнаруживает тайм-аут heartbeat и автоматически освобождает управление камерой, занятое этим iFay, предотвращая блокировку ресурсов «зомби-сеансами» на длительное время
Протокол CAP является ключевым мостом между интеллектуальными агентами и ресурсами терминала в экосистеме iFay — он не интересуется тем, кто такой Fay или что он умеет, а лишь тем, разрешено ли Fay выполнять определённое действие.
1.2 Обязанности, не входящие в сферу ответственности CAP
Для обеспечения чётких границ ответственности протокол CAP явно не отвечает за следующее:
- Создание и управление идентификацией Fay: Регистрация сущностей Fay, назначение идентификаторов, поддержка атрибутов идентификации и другие задачи выполняются подсистемой управления идентификацией в экосистеме iFay. CAP лишь использует информацию об идентификации для проверки авторизации и не участвует в процессе создания и управления идентификацией. Например, «как зовут этого iFay и кому он принадлежит» определяется системой управления идентификацией; CAP интересует лишь «разрешено ли этому iFay использовать камеру»
- Интеллектуальные способности Fay к рассуждению: То, как Fay понимает намерения пользователя, планирует шаги операций и выполняет интеллектуальные рассуждения, относится к интеллектуальному уровню самого Fay и не связано с протоколом CAP. CAP не делает никаких предположений и не предъявляет требований к уровню интеллекта Fay. Например, iFay решает сначала открыть браузер, а затем найти авиабилеты — этот процесс принятия решений не связан с CAP; CAP выполняет проверку авторизации только тогда, когда iFay фактически запрашивает открытие браузера
- Конкретная бизнес-логика ресурсов терминала: То, как программное обеспечение на терминале реагирует на команды операций и как аппаратное обеспечение выполняет конкретные функции, реализуется самими ресурсами терминала. CAP отвечает только за проверку авторизации и контроль доступа и не вмешивается в конкретную бизнес-обработку ресурсов. Например, как принтер форматирует страницы или какой картридж использует для печати — это собственная бизнес-логика принтера; CAP лишь проверяет, имеет ли iFay право использовать принтер
- Реализация сетевых протоколов связи: CAP определяет логический процесс проверки авторизации и формат сообщений, но не предписывает конкретный способ реализации базового сетевого транспортного протокола. Например, использует ли терминал для связи с iFay_Runtime WebSocket или gRPC — CAP не накладывает ограничений
- Внутренние механизмы безопасности операционной системы терминала: Собственные механизмы управления правами пользователей, изоляции песочницы, безопасности процессов и другие механизмы операционной системы не входят в юрисдикцию CAP. CAP взаимодействует с операционной системой через интеграционные интерфейсы. Например, механизм песочницы приложений Android управляется самим Android; CAP отправляет инструкции контроля доступа через интерфейсы, предоставляемые Android
1.3 Взаимосвязь с другими подпроектами
Протокол CAP в экосистеме iFay имеет чётко определённые взаимодействия со следующими подпроектами:
| Подпроект | Описание взаимосвязи | Граница взаимодействия |
|---|---|---|
| iFay_Runtime | Основной вызывающий компонент CAP. iFay_Runtime отвечает за управление жизненным циклом и планирование экземпляров Fay. Когда Fay необходим доступ к ресурсам терминала, iFay_Runtime инициирует запрос на управление от его имени | iFay_Runtime → CAP: инициирование запроса на проверку авторизации; CAP → iFay_Runtime: возврат результата проверки и информации о сеансе |
| Registration_Authority | Зависимость CAP от инфраструктуры доверия. Registration_Authority отвечает за регистрацию аппаратного обеспечения, программного обеспечения и операционных систем терминалов, а также за распространение ключей проверки (Verification_Key) на терминалы | Registration_Authority → Терминал: распространение Verification_Key; Терминал использует Verification_Key для проверки подписи Authorization_Descriptor |
| Descriptor_Issuer | Источник учётных данных авторизации для CAP. Descriptor_Issuer, авторизованный Natural_Person или Official_Post, отвечает за создание и выдачу Authorization_Descriptor | Descriptor_Issuer → Fay: выдача Authorization_Descriptor; Fay предъявляет Authorization_Descriptor при запросе доступа к терминалу |
| Подсистема управления идентификацией | Источник информации об идентификации для CAP. CAP ссылается на идентификатор Fay в процессе проверки авторизации, но не участвует в создании и управлении идентификацией | Управление идентификацией → CAP: предоставление информации об идентификаторе Fay (односторонняя зависимость) |
Принцип проектирования протокола CAP заключается в поддержании внутренней связности собственных обязанностей: выполнять только проверку авторизации и управление полномочиями, оставляя управление идентификацией, интеллектуальные рассуждения, бизнес-логику ресурсов и другие обязанности другим подпроектам экосистемы.
1.4 Область применения
Основная область применения протокола CAP: iFay принимает управление терминалом человека-хоста и использует программное обеспечение и аппаратные средства терминала так же, как это делает человек.
В этом сценарии человек-хост (Natural_Person) передаёт частичное или полное управление своим терминальным устройством своему iFay, который от его имени управляет клиентским программным обеспечением (например, браузером, почтовым клиентом, офисными приложениями) и аппаратными устройствами (например, камерой, микрофоном, устройствами хранения) на терминале. Протокол CAP обеспечивает в этом процессе:
- Легитимность авторизации: Терминал может проверить, что iFay действительно получил авторизацию от человека-хоста, а не осуществляет несанкционированный доступ. Например, если iFay Чжан Саня попытается управлять ноутбуком Ли Сы, терминал откажет в доступе из-за отсутствия учётных данных авторизации, выданных Ли Сы
- Офлайн-доступность: Даже если терминал находится в офлайн-режиме, при наличии у iFay действительного Authorization_Descriptor он по-прежнему может законно получать доступ к авторизованным ресурсам. Например, когда пользователь включает авиарежим в самолёте, его iFay может продолжать работать с офисным программным обеспечением на ноутбуке, используя предварительно сохранённый файл офлайн-авторизации
- Многосторонняя координация: Когда нескольким Fay или Fay и пользователям-людям одновременно необходим доступ к одному и тому же ресурсу терминала, протокол CAP обеспечивает возможности передачи управления и управления режимами доступа к ресурсам. Например, пользователь фотографирует на телефон, когда iFay тоже нуждается в камере для сканирования документа — протокол CAP координирует порядок использования между ними
- Безопасность и контролируемость: Все операции проверки авторизации и доступа к ресурсам могут быть подвергнуты аудиту, авторизация может быть отозвана в любой момент. Например, если пользователь обнаруживает аномальное поведение своего iFay, он может немедленно отозвать его авторизацию для всех ресурсов терминала, и активные сеансы iFay будут принудительно завершены
Та же структура протокола применима и к сценарию coFay — совместная сущность Fay, авторизованная официальной должностью (Official_Post), принимает управление терминальными устройствами организации для выполнения совместных задач.
1.5 Основные принципы проектирования
Протокол CAP следует основному принципу проектирования: офлайн — основной режим, онлайн — вспомогательный.
Офлайн-авторизация (Authorization_Descriptor) является основным механизмом. Терминальное устройство не должно полностью лишать Fay права на управление из-за недоступности сети. Если Fay заранее получил авторизацию от человека-хоста, это отношение авторизации должно быть сохранено в виде зашифрованного файла локально на терминале, позволяя терминалу самостоятельно выполнять проверку авторизации в офлайн-режиме. Authorization_Descriptor является конкретной реализацией этой концепции — это зашифрованный файл описания авторизации, хранящийся локально на терминале, содержащий область ресурсов, типы разрешений и срок действия, на которые авторизован Fay. Терминал может выполнить проверку с помощью локального Descriptor_Validator без подключения к сети.
Онлайн-билет (Trusted_Ticket) является дополнительным механизмом. В сетевой среде Trusted_Ticket обеспечивает возможности выдачи авторизации в реальном времени и запроса статуса отзыва, компенсируя недостатки офлайн-авторизации в отношении своевременности и скорости реагирования на отзыв. Когда онлайн-сервис доступен, терминал может получить актуальный статус авторизации через Trusted_Ticket; когда онлайн-сервис недоступен, терминал автоматически переключается на локальную проверку Authorization_Descriptor, обеспечивая непрерывность обслуживания.
Ключевые соображения этого принципа проектирования:
- Приоритет доступности: Прерывание сети не должно быть причиной неработоспособности Fay; офлайн-авторизация обеспечивает базовую доступность. Например, когда сигнал телефона пользователя прерывается в метро, iFay может продолжать работать с офлайн-приложениями на телефоне, используя локальный файл авторизации
- Усиление безопасности: Онлайн-билеты обеспечивают более сильные гарантии безопасности в реальном времени при наличии сети, включая мгновенный отзыв и динамическую корректировку разрешений
- Постепенная деградация: Переход от онлайн к офлайн является плавным и не приводит к внезапному прерыванию обслуживания; выданные онлайн Trusted_Ticket могут быть преобразованы в локальный формат Authorization_Descriptor для офлайн-использования. Например, пользователь авторизует своего iFay на использование камеры через онлайн-билет в зоне Wi-Fi; когда пользователь выходит из зоны покрытия Wi-Fi, авторизация автоматически переходит в офлайн-режим и продолжает действовать